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Foreword 



rd , 



This Technical Specification has been produced by the 3 Generation Partnership Project (3 GPP). 

The contents of the present document are subject to continuing work within the TSG and may change following formal 
TSG approval. Should the TSG modify the contents of the present document, it will be re-released by the TSG with an 
identifying change of release date and an increase in version number as follows: 

Version x.y.z 

where: 

X the first digit: 

1 presented to TSG for information; 

2 presented to TSG for approval; 

3 or greater indicates TSG approved document under change control. 

y the second digit is incremented for all changes of substance, i.e. technical enhancements, corrections, 
updates, etc. 

z the third digit is incremented when editorial only changes have been incorporated in the document. 
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Scope 



The present document is part of a series of documents that specify charging functionahty and charging management in 
3GPP networks(GSM/UMTS/EPS). The 3GPP core network charging architecture and principles are specified in 3GPP 
TS 32.240 [1], which provides an umbrella for other charging management TSs that specify: 

- the content of the CDRs per domain / subsystem / service (offline charging), 

- the content of real-time charging messages per domain / subsystem / service (online charging); 

- the functionality of online and offline charging for those domains / subsystems / services; 

- the interfaces that are used in the charging framework to transfer the charging information (i.e. CDRs or charging 
events) 

The complete document structure for these TSs is defined in TS 32.240 [1]. 

The present document specifies the transaction based mechanism for the near real time transfer of CDRs 
within the network. 

The present document is related to other 3 GPP charging TSs as follows: 

■ The common 3GPP charging architecture is specified in TS 32.240 [1]; 

■ The parameters, abstract syntax and encoding rules for the CDRs are specified in TS 32.298 [51]; 

■ The file based mechanism used to transfer the CDRs from the network to the operator's billing domain (e.g. the 
post-processing system or a mediation device) is specified in TS 32.297 [52]; 

The 3GPP Diameter application that is used for offline and online charging is specified in TS 32.299 [50]. 

All terms, definitions and abbreviations used in the present document, that are common across 3GPP TSs, are defined in 
the 3GPP Vocabulary, TR 21.905 [100]. Those that are common across charging management in 3GPP domains 
services, or subsystems are provided in the umbrella document TS 32.240 [1] and are copied into clause 3 of the present 
document for ease of reading. Finally, those items that are specific to the present document are defined exclusively in 
the present document. 

Furthermore, requirements that govern the charging work are specified in 3 GPP TS 22.115 [101]. 
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Release as the present document. 
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3 Definitions, symbols and abbreviations 

3.1 Definitions 

For the purposes of the present document, the terms and definitions given in 3GPP TR 21.905 [100], 3GPP TS 32.240 
[1] and the following apply: 

Billing Domain: part of the operator network, which is outside the telecommunication network that receives and 
processes charging information from the core network charging functions. It includes functions that can provide billing 
mediation and billing or other (e.g. statistical) end applications. It is only applicable to offline charging (see "Online 
Charging System" for equivalent functionality in online charging). 

CDR field Categories: defined in the middle tier charging TSs. CDR fields may be operator provisionable and are 
divided into the following categories: 

• Mandatory (M): field that shall always be present in the CDR. 

• Conditional (C): field that shall be present in a CDR if certain conditions are met. 

• Operator Provisionable: Mandatory (Om): field that, if provisioned by the operator, shall always be present in 
the CDR. 

• Operator Provisionable: Conditional (Oc): field that, if provisioned by the operator, shall be present in a CDR 
if certain conditions are met. 

charging: function within the telecommunications network and the associated OCS/BD components whereby 
information related to a chargeable event is collected, formatted, transferred and evaluated in order to make it possible 
to determine usage for which the charged party may be billed (offline charging) or the subscriber" s account balance 
may be debited / credited (online charging). 

Charging Data Record (CDR): formatted collection of information about one or more chargeable event(s) (e.g. time 
of call set-up, duration of the call, amount of data transferred, etc) for use in billing and accounting. For each party to be 
charged for parts of or all charges of the chargeable event(s) a separate CDR shall be generated, i.e. more than one CDR 
may be generated for a single chargeable event, e.g. because of its long duration, or because more than one charged 
party is to be charged. 

charging function: entity inside the core network domain, subsystem or service that is involved in charging for that 
domain, subsystem or service. 

circuit switched domain: domain within GSM / UMTS in which information is transferred in circuit switched mode. 

domain: part of the 3GPP telecommunication network that provides network resources using a certain bearer 
technology. 

GPRS: packet switched bearer and radio services for GSM and UMTS systems. 

middle tier (charging) TS: term used for the 3GPP charging TSs that specify the domain / subsystem / service specific, 
online and offline, charging functionality. These are all the TSs in the numbering range from 3GPP TS 32.250 to 3GPP 
TS 32.279, e.g. 3GPP TS 32.250 [10] for the CS domain, or 3GPP TS 32.270 [30] for the MMS service. Currently, 
there is only one "tier 1" charging TS in 3GPP, which is TS 32.240 [1] that specifies the charging architecture and 
principles. Finally, there are a number of top tier charging TSs in the 32.29x numbering range ([50] ff) that specify 
common charging aspects such as parameter definitions, encoding rules, the common billing domain interface or 
common charging applications. 

near real-time: near real-time charging and billing information is to be generated, processed, and transported to a 
desired conclusion in less than 1 minute. 

offline charging: charging mechanism where charging information does not affect, in real-time, the service rendered 

online charging: charging mechanism where charging information can affect, in real-time, the service rendered and 
therefore a direct interaction of the charging mechanism with session/service control is required. 
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packet switched domain: domain in which data is transferred between core network elements. 

real-time: real-time charging and billing information is to be generated, processed, and transported to a desired 
conclusion in less than 1 second. 



3.2 Symbols 



For the purposes of the present document, the following symbols apply: 



Be 

Bi 

Bl 

Bm 

Bmb 

Bo 

Bp 

Bs 

Bt 

Bw 

Bx 

Ga 
Rf 



Reference point for the CDR file transfer from the Circuit Switched CGF to the BD. 

Reference point for the CDR file transfer from the IMS CGF to the BD. 

Reference point for the CDR file transfer from the GMLC CGF to the BD. 

Reference point for the CDR file transfer from the MMS CGF to the BD. 

Reference point for the CDR file transfer from the MBMS CGF to the BD. 

Reference point for the CDR file transfer from the OCF CGF to the BD. 

Reference point for the CDR file transfer from the Packet Switched CGF to the BD. 

Reference point for the CDR file transfer for CAMEL services to the BD, i.e. from the SCF CGF 

to the BD. 

Reference point for the CDR file transfer from the PoC CGF to the BD. 

Reference point for the CDR file transfer from the /-WLAN CGF to the BD. 

Reference point for CDR file transfer between any (generic) 3G domain, subsystem or service 

CGF and the BD. 

Reference point for CDR transfer between a CDF and the CGF. 

Offline Charging Reference Point between the CTF within a 3G network entity and the CDF. 



3.3 



Abbreviations 



For the purposes of the present document, the following abbreviations apply: 

bed binary coded decimal 

BD Billing Domain 

CAMEL Customised Applications for Mobile network Enhanced Logic 

CDF Charging Data Function 

CDR Charging Data Record 

CGF Charging Gateway Function 

CS Circuit Switched 

CTF Charging Trigger Function 

EPS Evolved Packet System 

E-UTRAN Evolved Universal Terrestrial Radio Access Network 

FTP File Transfer Protocol 

GMLC Gateway MLC 

GPRS General Packet Radio Service 

IMS IP Multimedia Subsystem 

IP Internet Protocol 

IPDR Internet Protocol Detail Record 

I-WLAN Interworking WLAN 

LAN Local Area Network 

MBMS Multimedia Broadcast/Multicast Service 

MLC Mobile Location Center 

MMS Multimedia Messaging Service 

OAM&P Operation, Administration, Maintenance and Provisioning 

OCF Online Charging Function 

OCS Online Charging System 

PoC Push-to-talk over Cellular 

PS Packet Switched 

SCF Service Control Function 

UTC Universal Time Coordinated 

WLAN Wireless LAN 
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Architecture considerations 



"Bx" is a common designator for the reference points from the network to the bilHng domain (BD) that are intended for 
the transport of CDR files. The letter "x" indicates the different 3GPP network domain, subsystem or service, where 

c represents Circuit Switched (CS) in TS 32.250 [10], 

p represents Packet Switched (PS) in TS 32.25 1 [1 1], 

i represents IP Multimedia Subsystem (IMS) in TS 32.260 [20], 

1 represents Location Service (LCS) in TS 32.271 [31], 

m represents Multimedia Messaging Service (MMS) in TS 32.270 [30], 

mb represents Multimedia Broadcast/Multicast Service (MBMS) in TS 32.273 [33], 

o represents the Online Charging System (OCS) in TS 32.296 [53], 

t represents the PoC service (PoC) in TS 32.272 [32], 

s represents the CAMEL SCF in TS 23.078 [200], and 

w represents interworking Wireless LAN (I-WLAN) in TS 32.252[12]. 

By definition, dealing with CDR files only implies that Bx is solely related to offline charging. The following figure 
depicts the position of the Bx reference point within the overall 3GPP offline charging architecture. 



CN 
Domain 



Service 
nodes 



Sub- 
system 



3GPP network 




Bx 



Billing 
Domain 



CTF: Charging Trigger Function 

CDF: Charging Data Function 

CGF: Charging Gateway Function 

BD: Billing Domain. This may also be a billing system/ billing mediation device. 

Figure 4.1 : Logical ubiquitous offline charging architecture 

As illustrated in figure 4.1, the CGF in each network domain, service or subsystem is relevant for the network side of 
the Bx reference point and is connected with the BD that forms the receiving end of the Bx reference point. Further 
details of the Billing Domain, i.e. beyond terminating Bx, are outside the scope of 3GPP standardization. Refer to 
3GPP TS 32.240 [1] for the complete description of the 3GPP charging architecture. 
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Note that the OCS can also generate CDRs and transfer them to the BD across the Bo reference point (not depicted in 
figure 4.1). Refer to 3GPP TS 32.296 [53] for further information on the OCS. 

Furthermore the GSM SCF, defined in CAMEL, can also generate CDRs and transfer them to the BD across the Bs 
reference point (not depicted in figure 4.1). Refer to 3GPP TS 23.078 [200] for further information on CAMEL. 



5 CDR File Transfer Principles and Scenarios 

This clause contains specifications for the principles and scenarios covering the CDR file transfer interface from the 
networlc to the Billing Domain. These specifications apply to all domains, subsystems and services that are listed in 
clause 4, including the OCS Bo and the GSM SCF"s Bs interface. Alternatively, in the CS domain (i.e. for Be), the file 
transfer mechanism specified in 3GPP TS 32.250 [10] may be used. Consequently, for Be it is up to implementation 
choice to provide either the legacy interface, the interface specified in the present document, or both. 

The scenarios in this clause are divided into the following categories: 

• Local CDR and CDR file handhng; 

• File format principles; 

• File Transport and protocol; 

• File transfer modes and session management. 

Other interface principles such as security and performance are dependent on vendor implementation and operator's 
network design and are not covered by the present document. 

5.1 Local CDR and CDR file handling 
5.1.1 CDR processing 

As depicted in figure 4.1. above, the CGF collects CDRs from the CDF. If the CDF and the CGF are separate entities, 
then the standard Ga interface as specified in 3GPP TS 32.295 [54] is used to transfer the CDRs from the CDF to the 
CGF. If CDF and CGF are integrated, then a proprietary, internal mechanism is used. The possibilities of separate or 
integrated CDF and CGF are specified per domain, subsystem and service in the respective "middle tier" charging TS, 
i.e. those in the [10] through [49] reference number range, and in TS 32.296 [53] for the OCS. 

In any case, CDRs are transferred, in near real time, from the CDF to the CGF as soon as they have been closed by the 
CDF. Refer to 3GPP TS 32.295 [54] for further details. Once received by the CGF, the CDRs may undergo semantical 
and/or syntactical sanity checks, however, these checks are not specified further within the present document. 

If the CGF determines that a CDR is not well formatted, or otherwise incorrect, then the defective CDR parameter(s) 
shall be filled with an appropriate "replacement" indicator within the limits of the syntax allowed for the parameter. If 
the error renders the complete CDR unusable (i.e. the above replacement of erroneous parameters is not possible), then 
no further action of the CGF can be performed regarding this CDR. An example of a case where the erroneous 
parameter cannot be replaced is when the "CDR type" attribute of a CDR received by the CGF is corrupted. Details of 
this function are implementation specific. 

CDRs that have been processed by the CGF without error, or where errors have been corrected by the CGF as described 
above, are considered "acceptable" by the CGF. CDRs that have non-recoverable errors are not considered "acceptable" 
by the CGF. The "acceptable" CDRs are immediately placed into a CDR file by the CGF. The CDRs that are not 
"acceptable" should be properly reflected in an error log and appropriate alarms should be generated, after which they 
may be destroyed. Furthermore, to the extent possible, the number of lost CDRs and the fact that CDRs were lost, shall 
be indicated in the CDR file. 

It is acknowledged that the processing of a CDR between being received until it is placed on the CDR file, will take a 
small amount of time. Hence, where the present document mandates the "immediate" treatment of CDRs received by 
the CGF, it is to be interpreted such that it is not allowed to postpone the processing of any received CDRs for any 
reason. In technical terms, "immediate" shall be interpreted as 
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• The system shall be capable of complying with near real time requirements as specified in subclause 3.1. 

• The system should be capable of complying, as closely as possible, with real time requirements as specified in 
subclause 3.1. 

Once a CDR has been stored on the appropriate file, the CGF may destroy any other reference to that CDR. 

5.1.2 CDRrouteing 

In the default mode of operation, the CGF manages a single ("default") file for the storage of all "acceptable" CDRs. 
However, the CGF may also route CDRs to different files that are kept open concurrently, i.e. additional files may be 
configured by 0AM &P commands together with associated CDR routeing filters. While the CGF will store only those 
CDRs matching the associated routeing filter on each of the additional files, the default file is used to store all CDRs 
that do not match any of the routeing filters configured for the additional files. 

The CDR routeing function shall apply CDR parameters and CDR origin to decide into which file to place the CDR. 
The file name shall, within the limits of the file naming conventions, contain an indication of the CDR routeing filter 
applied. 

As a minimum, each CGF implementation shall support the CDR type and the sending CDF as selection criteria for 
CDR routeing. It shall then be possible to include in a file only the following CDRs: 

• CDRs of a single type; 

• CDRs of a set of specified types (e.g. only IMS CDR types); 

• CDRs originated by a single CDF; 

• CDRs originated by a set of CDFs; 

• Any combination of the above. 

Further details of the CDR routeing function, such as 

• the maximum number of simultaneously open CDR files; 

• the order in which the routeing filters are evaluated; 

• the way CDR filters can be configured by OAM&P; 

are implementation specific. In order to avoid arbitrary routeing of CDRs, operators should assure that the routeing 
filters assigned per file, do not overlap with each other. 

The term "matching CDR" is used in the present document to denote a CDR that matches the routeing filter of a given 
CDR file. 

5.1 .3 Local CDR file management 

For the default case, plus each of the additional CDR routeing filters that may be set up on the CGF (cf. subclause 5.1.2 
above), the CGF provides a non-interrupted chain of CDR files. As described above, each CDR is immediately stored in 
the appropriate file after being received and determined "acceptable" by the CGF. 

Several conditions may govern the closure of a CDR file by the CGF: 

• A configurable file size limit; 

• A configurable file closure time; 

• A configurable file lifetime ("interval"); 

• A configurable number of CDRs within the file; 

• CDR release, version or encoding change; 
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• Manual 0AM &P actions; 

• System defined reasons (e.g. file system full). 

When a CDR file is closed, the next matching CDR shall be placed in the next file in the chain. The exact time when 
this next CDR file is physically generated, i.e.: 

• immediately after the previous file has been closed (i.e. the earliest possible time), 

• when the next matching CDR arrives (i.e. the latest possible time), 

• anytime in between, 

is implementation specific. However, each CDR file must contain all "acceptable" matching CDRs received and 
processed by the CGF between the closure of the previous file and the configured file closure trigger of the current file, 
as specified above. In any case, a file must be generated and closed upon the occurrence of the file closure trigger, 
i.e. an empty file (containing no CDRs) if no matching CDRs arrived since the closure of the last file in the chain. Upon 
file closure, the CDR file is immediately available for transfer to the BD. 

CDR files may be removed from the CGF in one of the following ways: 

• By the BD issuing corresponding commands provided by the file transfer protocol; 

• By the CGF application once the file has been transferred; 

• Due to CGF file system storage limitation or configurable file age limits; 

• OAM&P action. 

In order to avoid loss of CDRs, Operators should manage the system in a way that the "system defined" file closure 
triggers mentioned above do not occur. 
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5.2 File format principles 

The CDR file format is depicted below. 



Concatenated CDRs 



Header with Specified Lengtii 




CDR1 


CDR 2 


CDRS 


CDR 4 


CDRS 




CDRn 



Figure 5.2.1 : CDR File Format 

The CDR files contain a variable length header section followed by a variable sized CDR data section. The CDR data 
section contains zero or more concatenated CDRs. Each CDR in a file includes a header indicating the CDR length, data 
record format, release, version and encoding scheme. 

The BD should use a decoder with a version number which is equal or greater of this version to be able to decode all the 
CDRs in the file. 

Clause 6 of the present document specifies the file format applying the above principles at bit level detail. 
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5.3 File Transport and protocol 

Two mechanisms are defined for the transport of CDR files from the CGF to the BD: 

• A basic transport mechanism is defined in subclause 5.3.1 and must be supported by all CGF implementations; 

• The use of the File Transfer IRP as described in subclause 5.3.2 may additionally be supported by the CGF as 
an implementation option. 

The use of IPDR as described in subclause 5.3.3 may optionally be supported on the Bx reference point. 

5.3.1 Basic file transport mechanism 

The following stipulations govern the choice and usage of file transport protocol for this transport mechanism. 

a) The default protocol for CDR file transport is FTP (RFC 959 [400]). 

b) The use of other protocols is optional, however FTP must always be supported. 

c) The CDR files may be transferred in either push or pull mode on the Bx interface. Further specifications of these 
transfer modes are provided in subclause 5.4.1 and subclause 5.4.2, respectively. 

d) All standard FTP commands specified in RFC 959 [400] shall be supported by the CGF. 

All further requirements specified within the present document with reference to the operation of the file transfer 
protocol in this mechanism (cf. clause 6), are solely related to FTP as the transfer protocol, as no assumptions can be 
made as to the ways of working of optional other protocols. However, additional protocols shall be implemented such 
that, to the extent possible, the same logic is applied as described in the present document for FTP. 

5.3.2 Use of File Transfer IRP 

The File Transfer IRP is specified in 3GPP TSs 32.341 [500], 32.342 [501], 32.343 [502] and 32.344 [503]. The support 
of the solution sets (CORBA, CMIP or both) is left to implementation choice. Otherwise, the CGF implementation of 
the IRP shall comply with the above TSs, i.e. there are no further additions or limitations with regard to the use of the 
IRP in charging. 

5.3.3 Use of IPDR 

As depicted in ATIS-PP-0300075.1.200X [401] IPDR file transfer or streaming protocol can be used for the Bx 
reference point. 

The IPDR file transfer is specified in IPDR/File Transfer Protocol [402] . The IPDR streaming protocol is specified in 
IPDR/SP [403]. 
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5.4 File transfer modes and session management 

5.4.1 Basic file transfer mechanism 

Files can be transferred to the BD in one, or both, of the following modes. Detailed FTP file transfer and session 
management procedures are specified in clause 6. 

5.4.1.1 Push mode 

In this transfer mode the CDR files are written from the CGF to the BD filestore at a time and/or frequency controlled 
by the CGF. I.e. the CGF pushes the files to the BD. This implies that the CGF operates in client mode and the BD in 
server mode. If the CGF generates concurrent CDR files based on the CDR routeing function specified in 
subclause 5.1.2, then it shall be able to send the different files to different BD systems, i.e. the BD address is part of the 
CDR file routeing filter. 

As a minimum, the following events shall be capable of triggering a file push in the CGF: 

• A (configured number of) new CDR file(s) has become available for transmission; 

• The CDR file / files has / have exceeded a configurable (total) size limit; 

• A configurable, regular time interval has elapsed; 

• The CGF filestore utilization has exceeded a configurable level. 

If the file transfer fails, the CGF should properly reflect this in an error log and generate appropriate alarms. Possible 
measures to handle file transfer failures are discussed in clause 6. 

Security measures, e.g. the mutual identification / verification of the peer systems, are outside the scope of the present 
document. 

5.4.1.2 Pull mode 

In this transfer mode the BD reads the CDR files that are available in the appropriate CGF directories. The time and/or 
frequency of the file transfer is controlled by the BD. I.e. the BD pulls the files from the CGF. This implies that the 
CGF operates in server mode and the BD in client mode. 

In this mode, the BD may request the files from the CGF at any point in time at the discretion of the BD, i.e. the CGF 
cannot make any assumptions of the time or frequency of the file pull to occur. If the file transfer fails, any further 
action is up to the BD, however, the CGF should properly reflect this in an error log and generate appropriate alarms. 
Possible measures to handle file transfer failures are discussed in clause 6. 

Security measures, e.g. the mutual identification / verification of the peer systems, are outside the scope of the present 
document. 

5.4.2 Use of File Transfer IRP 

File transfer modes and session management using the optional File Transfer IRP are governed by 3GPP TSs 
32.341 [500], 32.342 [501], 32.343 [502] and 32.344 [503]. 

5.4.3 Useof IPDR 

File transfer mode and session management using the optional IPDR protocols are governed by IPDR File Transfer 
[402] or streaming protocol [403]. 
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CDR file format specification 



This clause provides detail specifications for the CDR file format. These specifications apply to all domains, 
subsystems and services listed in clause 4. Alternatively, in the CS domain (i.e. for Be), the file transfer mechanism 
specified in 3GPP TS 32.250 [10] may be used. Consequently, for Be it is up to implementation choice to provide either 
the legacy interface, the interface specified in the present document, or both. 

The file format specification in this clause is divided into the following categories: 

• File format conventions; 

• File naming and directory conventions; 

• Detailed file transfer and session management procedures. 

• Error handling 

Only the basic file transfer mechanism is covered in the present document. Refer to 3GPP TSs 32.341 [500], 
32.342 [501], 32.343 [502] and 32.344 [503] for the corresponding details when using the optional File Transfer IRP 
and [402], [403] when using the optional IPDR protocols. 

6.1 File format conventions 

The file format shall apply the following conventions. 

a) The CDR files contain a variable length file header immediately followed by a variable number (zero or more) of 
concatenated CDRs which are structured according to the CDR format specified in the middle tier charging TSs. 

b) The syntax and encoding rules for the CDRs are specified in 3GPP TS 32.298 [51]. 

c) Each CDR is immediately preceded by a fixed length plain text header. 

d) The file header fields and CDR header fields are in Network byte order (Big Endian). 

e) The file header contains fields specified in subclause 6.1.1. 

f) The CDR header contains fields specified in subclause 6.1.2. 

g) File header fields that are not known at the time the file is opened are populated after all the CDRs are included 
and the file is ready to be closed. 

The CDR file is named based on the naming convention specified in clause 6.2. 



ETSI 



3GPP TS 32.297 version 8.2.0 Release 8 



19 



ETSI TS 132 297 V8.2.0 (2009-07) 



6.1 .1 CDR file header format 

The exact format of the CDR file header is given in table 6.1..1. 



Table 6.1 .1 : Format of CDR File Header 



Bits 


Octets 


8 1 7 1 6 |5|4|3|2|1 


1..4 


File length 


5.-8 


Header length 


9 


High Release Identifier 


High Version Identifier 


10 


Low Release Identifier 


Low Version Identifier 


11. .14 


File opening timestamp 


15.. 18 


Timestamp when last CDR was appended to file 


19..22 


Number of CDRs in file 


23..26 


File sequence number 


27 


File Closure Trigger Reason 


28..47 


IP Address of Node that generated file 


48 


Lost CDR indicator 


49..50 


Length of CDR routeing filter 


51. .xy 


CDR routeing filter 


xy+1..xy+2 


Length of Private Extension 


xy+3..n 


Private Extension 



The following subclauses specify the contents and encoding of the CDR file header fields. Unless otherwise specified in 
the subclauses below, all parameters are mandatory and shall always be included in a CDR file header. 



6.1.1.1 



File length 



The "file length" parameter contains a binary value that identifies the total length of the CDR file in octets, including 
the file header and the total CDR payload length. 

The value with all bits set to "1" is reserved for future extensions (e.g. for CDR files longer than that value) and shall 
therefore not be used. 

6.1.1.2 Header length 

The "header length" parameter contains a binary value that identifies the total length of the CDR file header in octets. 

The value with all bits set to "1" is reserved for future extensions (e.g. for CDR file headers longer than that value) and 
shall therefore not be used. 

6.1 .1 .3 High release / version identifier 

This field is a copy of octet 3 of the CDR header. It is copied from the CDR where the equation: 

Release Identifier * 100 + Version Identifier 

yields the highest result of all CDRs in the file. The representation of Release Identifier and Version Identifier in this 
field is the same as in octet 3 of the CDR header. 

6.1 .1 .4 Low release / version identifier 

This field is a copy of octet 3 of the CDR header. It is copied from the CDR where the equation: 

Release Identifier * 100 + Version Identifier 

yields the lowest result of all CDRs in the file. The representation of Release Identifier and Version Identifier in this 
field is the same as in octet 3 of the CDR header. 
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6.1 .1 .5 File opening timestamp 

These parameters indicate the time when the file was opened, according to the following binary format: 

■ The first four binary bits indicate the month (1 .. 12), according to the CGF"s local time zone; 

■ The next five binary bits contain the date (1 :: 31), according to the CGF"s local time zone; 

■ The next five binary bits contain the hour (0 .. 23), according to the CGF"s local time zone; 

■ The next six binary bits contain the minute (0 .. 59), according to the CGF"s local time zone; 

■ The next bit indicates the sign of the local time differential from UTC (bit set to "1" expresses "+" or bit set 
to "0" expresses "-" time deviation), in case the time differential to UTC is then the sign may be 
arbitrarily set to "+" or "-"; 

■ The next five binary bits contain the hour (0 .. 23) deviation of the local time towards UTC, according to 
the CGF"s local time zone; 

■ The next six binary bits contain the minute (0 .. 59) deviation of the local time towards UTC, according to 
the CGF"s local time zone; 

Note that the CDR file name contains detailed date and time information related to file closure (cf. clause 6.2) 

6.1 .1 .6 Last CDR append timestamp 

This parameter is formatted the same as in 6.1.1.5, and indicates the time when the last CDR was appended to the file in 
UTC format. In case of an empty file (i.e. no CDRs included), the value of the parameter is "0". 

6.1 .1 .7 Number of CDRs in file 

This parameter contains a binary value that specifies the total number of CDRs that are included in the file. 

The value with all bits set to "1" is reserved for future extensions (e.g. for CDR files containing more CDRs than 
represented by that value) and shall therefore not be used. 

6.1 .1 .8 File sequence number 

This parameter is a value in binary that contains a running number of the CDR file generated by the same CGF. The 
first file of a CGF is indicated by the value "0". When the maximum number of file is reached (all bits set to "1"), the 
sequence shall be restarted with "0". 

6.1 .1 .9 File Closure Trigger Reason 

The file closure reason provides a means to determine the reason that the file was closed by the CGF. It is encoded as a 
single octet as follows. 

Normal closure reasons (Binary values to 127): 

= Normal closure (Undefined normal closure reason). 

1 = File size limit reached (OA&M configured). 

2 = File open-time limit reached (OA&M configured). 

3 = Maximum number of CDRs in file reached (OA&M configured). 

4 = File closed by manual intervention. 

5 = CDR release, version or encoding change. 

6 to 127 are reserved for future use. 
Abnormal closure reasons (Binary values 128 to 255): 
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128 = Abnormal file closure (Undefined error closure reason). 

129 = File system error. 

130 = File system storage exhausted. 

131 = File integrity error. 

132 to 255 are reserved for future use. 

6.1.1.10 Node IP address 

This parameter indicates the IP address of the CGF generating the file. For both IPv4 and IPv6 CGF addresses, the 
parameter is encoded in IPv6 representation. The first four bytes of the parameter, which are preceeding this IPv6 
address, are insignifant, e.g. filled with "FF". 

6.1.1.11 Lost CDR indicator 

This parameter indicates if and how many CDRs were lost during their processing in the CGF (cf. clause 5.1.1). The 
term "lost" implies that the CDR(s) could not be placed into the destination file due to irrecoverable errors. 

Due to the possibility that the irrecoverable CDR errors may have impacted CDR parameters that are relevant for CDR 
routeing, it is possible that the CGF cannot determine for a particular file whether CDRs have been lost. Appropriate 
indication shall be given according to the following encoding of the "lost CDR indicator". 

■ MSB bit "0", all other bits "0": no CDRs have been lost; 

■ MSB bit "0", all other bits set to a value corresponding to decimal 1 to decimal 126: CGF has identified 
that a number of CDRs corresponding to the value of the lower 7 bits were lost, while it is unknown 
whether more CDRs were lost; 

■ MSB bit "0", all other bits set to "1": CGF has identified that 127 or more CDRs were lost, while it is 
unknown whether more CDRs were lost; 

■ MSB bit "1", all other bits "0": CDRs have been lost but CGF cannot determine the number of lost CDRs; 

■ MSB bit "1", all other bits set to a value corresponding to decimal 1 to decimal 126: CGF has calculated the 
number of lost CDRs as indicated in the value of the lower 7 bits; 

■ MSB bit "1", all other bits set to "1": CGF has calculated the number of lost CDRs to be 127 or more. 

6.1 .1 .12 Length of CDR routeing filter 

This parameter contains a binary value that specifies the length of the subsequent CDR routeing filter in octets. The 
value excludes the two octets of the "length" parameter itself. 

The value of "65535" (all bits set to "1") is reserved for future extensions (e.g. for CDR routeing filters longer than 
65534 octets) and shall therefore not be used. 

6.1.1.13 CDR routeing filter 

This parameter indicates the filter that determined the routeing of CDRs into this file. Its encoding is vendor specific. 

6.1.1.14 Length of private extension 

This parameter contains a binary value that specifies the length of the subsequent "private extension" field in octets. It is 
present only if a private extension field is included in the CDR file header. Its value excludes the two octets of the 
"length" parameter itself. 

The value of "65535" (all bits set to "1") is reserved for future extensions (e.g. for private extensions longer than 65534 
octets) and shall therefore not be used. 
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6.1.1.15 



Private extension 



This optional field contains a vendor specific private extension to the CDR file header, if any. Its encoding, if present, is 
vendor specific. 

6.1.2 CDR header format 

The exact format of the CDR header is given in table 6.1.2. 

Table 6.1.2: Format of CDR Header 



Bits 


Octets 


8 1 7 1 6 


5 1 4 


1 3 1 2 1 


1 . 


1..2 


CDR length 


3 


Release Identifier 


Version Identifier 


4 


Data Record Format 


TS number 



The following subclauses specify the contents and encoding of the CDR header fields. 



6.1.2.1 



CDR length 



This two octet field contains a binary value that specifies the length of the subsequent CDR, excluding the 4 header 
octets. The value of "65535" (all bits set to "r')in the CDR length field implies that it is reserved for future extensions 
and shall therefore not be used. 



6.1.2.2 



Release Identifier 



This three bit field contains a binary value that identifies the 3GPP Release of the Technical Specification indicated in 
"TS number" (see clause 6.1.2.5). Its value is set / used according to the following rules: 

Table 6.1.2.2: Release Identifier 



Release 

Identifier 

(3 bits) 


3GPP 
Release 


Indicates 3GPP "TS number" for the release 


Comment , 


"0" 


Rel-99 


32.005 or 32.01 5 


this parameter shall be 
ignored 


"1" 


Rel-4 


32.205, 32.21 5 or 32.235 




"2" 


Rel-5 


32.205, 32.215, 32.225 or 32.235 




"3" 


Rel-6 


32.250, 32.251 , 32.252, 32.260, 32.270, 32.271 , 32.272 or 32.273 




"4" 


Rel-7 


32.250, 32.251, 32.252, 32.260, 32.270, 32.271, 32.272 or 32.273 




"5" 


Rel-8 


32.250, 32.251, 32.252, 32.260, 32.270, 32.271, 32.272 , 32.273 or 
32.275 




NOTE: Additional "Release Identifier" incremented by "1", up through 7, indicate subsequent releases 



6.1.2.3 



Version Identifier 



This five bit field contains a binary value that identifies the version of the 3GPP Technical Specification up through 31, 
as indicated in "TS number" (see 6.1.2.5 below). Its value corresponds to the middle digit of the version number of that 
TS, as indicated on the TS cover sheet. 

6.1 .2.4 Data Record Format 

This three bit field contains a binary value that identifies the CDR encoding according to the following table: 

■ "1" signifies the use of Basic Encoding Rules (BER); 

■ "2" signifies the use of unaligned basic Packed Encoding Rules (PER); 

■ "3" signifies the use of aligned basic Packed Encoding Rules (PER); 
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■ "4" signifies the use of XML Encoding Rules (XER). 

6.1.2.5 TS number 

This five bit field contains a binary value that identifies the number of the TS CDR encoding according to table 6.1.2.5: 

Table 6.1.2.5: "TS number" Identifier 



"TS number" Identifier (5 bits) 


TS number 





32.005 


1 


32.015 


2 


32.205 


3 


32.215 


4 


32.225 


5 


32.235 


6 


32.250 


7 


32.251 


8 


32.252 


9 


32.260 


10 


32.270 


11 


32.271 


12 


32.272 


13 


32.273 


14 


32.275 


NOTE: 1 5-31 are for future use. 



6.2 CDR file naming convention 



The file naming convention ensures that CDR file names are unique among a large number of CGF nodes over an 
extended period of time (at least several months). In order to accomplish this requirement, the file name includes the 
following information: 

<NodeID>_-_<RC>.<date>_-_<time>[.<PI>][.<FE>] 

1) NodelD. This is the name of the CGF that generated the file. When the CGF is integrated in another node (see 
3GPP TS 32.240 [1]), then this parameter contains the NodelD of the node that the CGF is integrated in. 

2) The RC parameter is a running count, starting with the value of " 1 " . Note that the delimiter preceding this field is 
made up of an underscore character (_), followed by a minus character (-), followed by another underscore 
character (-). 

3) The "date" field indicates in ASCII, the date when the CDR file was closed. It is of the form YYYYMMDD, 
where: 

- YYYY is the year in four-digit notation; 

MM is the month in two digit notation (01 - 12); 

- DD is the day in two-digit notation (01 - 31). 

Note that this field is preceded by a point (.) character as delimiter. 

4) The "time" field indicates in ASCII, the time when the CDR file was closed. It is of the form HHMMshhmm, 
where: 

- HH is the two-digit hour of the day (local time), based on 24-hour clock (00 - 23); 
MM is the two digit minute of the hour (local time); 

- s is in ASCII, the sign of the local time differential from UTC (+ or -), in case the time differential to UTC is 
then the sign may be arbitrarily set to "+" or "-"; 

- hh is the two-digit number of hours of the local time differential from UTC (00-23); 
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- mm is the two digit number of minutes of the local time differential from UTC (00-59). 

Note that the delimiter preceding this field is made up of an underscore character (_), followed by a minus 
character (-), followed by another underscore character (-). 

5) Optional private information. The content of this field is implementation specific. This field, if present, is 
preceded by a point (.) character delimiter. 

6) Optional file extension. The content of this field is implementation specific. This field, if present, is preceded by 
a point (.) character delimiter. 

Some examples describing file-naming convention (note that the quotation marks do not form part of the file name): 

1) filename: "CGFNodeId_-_1234.20050401_-_2315+0200", 

meaning: file #1234 produced by CGF <CGFNodeId> on April 1, 2005 at 23:15 local time, with a time 
differential of +2 hours against UTC. 

2) file name: "CGFNodeId_-_44.20051224_-_1700-1130.thankgoditschristmas.abc", 

meaning: file #44 produced by CGF <CGFNodeId> on December 24, 2005 at 17:00 local time, with a time 
differential of -11:30 hours against UTC, private information "thankgoditschristmas" and extension "abc". 

3) filename: "CGFNodeId_-_44.20051224_-_1700-1130..abc", 

meaning: same file as 2) above but this time without private extension. Note that there are two point characters 
(.) preceding the file extension due to the missing (=empty) private extension. 

There shall be a configurable base directory on the CGF which contains one or more subdirectories that contain all 
CDR files that are ready for transfer to the BD. Further details of the directory structure on the CGF for the storage of 
CDR files are implementation specific. 

6.3 Detailed FTP transfer and session management procedures 

The detailed FTP transfer and session management procedures are out of scope of the current 3GPP release. However 
the following items should be considered in actual implementations. 

• FTP client behaviour; 

• FTP server role; 

• File transfer triggers; 

• Each of the above in relation to push and pull modes. 



6.4 Error iiandling 



The detailed error handling on the CGF is out of scope of the current 3 GPP release. However the following items 
should be considered in actual implementations. 

• Replacement of invalid CDR parameters; 

• Handling of irrecoverable CDRs; 

• System dependent failures (file system full, etc.); 

• File transfer failure in relation to 

■ Pull mode; 

■ Push mode. 
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